Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Richer project descriptions #48

Open
4 tasks
gambogi opened this issue Aug 25, 2016 · 14 comments
Open
4 tasks

Proposal: Richer project descriptions #48

gambogi opened this issue Aug 25, 2016 · 14 comments

Comments

@gambogi
Copy link
Member

gambogi commented Aug 25, 2016

Just going to toss out an idea myself and others have been kicking around for a few years that I'd really like to see implemented.

It would be nice to take advantage of the fact we require descriptions of projects for submission to eboard for PR/record keeping purposes. Concretely, I'd like the following functionality (and happy to implement myself):

  • project descriptions may include some form of richer text, preferably markdown or something similar, possibly user choice.
  • Images and other attachments (but hopefully not malicious code) may be attached.
  • Projects must be marked as published in some fashion. Ideally anything that is a major project should be worth bragging about.
  • Public facing project blog should be exposed, attributing contributions to project authors, this should either be linked to by the main site or incorporated.
@liam-middlebrook
Copy link
Member

I like the general idea of this issue. Although I'm not sure conditional is the proper platform for aggregation. I proposed a similar issue to this over the Summer on the Public Site ComputerScienceHouse/CSHPublicSite#140

I was considering something like this earlier today and personally came to the conclusion that removing projects over time to avoid our current issue is tricky. I wouldn't want the site at week 0 to appear as if no projects had been done. But I'm also not sure that cutting off the list that's sorted by submission date is the right way to go either. Earlier in development there was discussion about creating a project up vote system. Some concerns about it encouraging a toxic culture were brought up. I'm not sure if that as a way to export projects within the past year or so would be a good way to generate a list, but I'm certainly open to discussion.

@mbillow
Copy link
Member

mbillow commented Feb 8, 2017

This library looks really good and perfect for what we want. It should be super simple to implement and a great step towards our end goal of publishing. https://github.com/NextStepWebs/simplemde-markdown-editor

@gambogi
Copy link
Member Author

gambogi commented Feb 8, 2017

Wait we agree on publishing? That's great news

@mbillow
Copy link
Member

mbillow commented Feb 8, 2017

There is a lot in between us and that goal, but I definitely want to see it happen!

@audiolion
Copy link
Member

By being marked as published, is that a decision by the project owner? E.g. they can mae their project page and iterate privately before publishing it?

@mbillow
Copy link
Member

mbillow commented Feb 8, 2017

@audiolion The publishing would be left up to Eboard in the current plan. So, as a cool project is submitted, Eboard can approve it and then publish it.

@gambogi
Copy link
Member Author

gambogi commented Feb 8, 2017

@audiolion I would hope so.

@liam-middlebrook
Copy link
Member

I don't think we should get ahead of the immediate goal here of having descriptions that are being shown in conditional written and rendered in markdown.

I'm definitely in favor of updating the public website with more recent major projects, but that's more long term and will require many changes on both conditional and the public site in order to work out.

@gambogi
Copy link
Member Author

gambogi commented Feb 8, 2017

If you want to talk about an immediate goal do so in a different issue. This is the proposal thread where the end goal should be discussed.

@audiolion
Copy link
Member

So @mbillow's proposal is that eboard publishes, @gambogi's proposal is that the project owner publishes. Maybe these are two separate pieces, the project owner can iterate and once they are ready submit the proposal, a flag is set in the database to put it in a queue for eboard to review, if eboard accepts it is published, if they reject it the flag is unset and the project owner can make changes and submit again?

@mbillow
Copy link
Member

mbillow commented Feb 8, 2017

I don't think it has to be that complicated. If The person puts enough effort into their post they are expressing their want to have it published. Eboard can then review for the externally noteworthy and publish those. By the way, I don't mean to diminish the value of all projects, but it seems like a bit much to publish 60-70 projects every year. That is why I think Eboard is a good group to make said decision, since they are required to be familiar with all passed projects.

@gambogi
Copy link
Member Author

gambogi commented Feb 8, 2017 via email

@stevenmirabito
Copy link
Collaborator

I agree with @gambogi. We should explain that we're doing this and the benefits of having their work published, and if they don't want to have it published they can uncheck "consider for publishing" when they submit their project. Then, eboard can say "yep, this looks cool" and publish it after they pass it.

@gambogi
Copy link
Member Author

gambogi commented Feb 10, 2017

Also @mbillow part of why I want to see this publishing thing go through is exactly because we do 60-70 projects a year. That's awesome, and barely anyone outside of the organization can see that right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants