Hi, subprojects (and using any other redmine feature) is okay as long as there is some good use for it, and I think if someone starts to use some feature in some way that causes trouble for others then I think we can make it stop quite quickly. Having a subproject for infrastucture seems good idea since it will have totally unrelated tickets (and wiki documents?) to developing Replicant I think. Well maybe not in OTA update case but Redmine tickets can link to each other across projects so it should not be a problem.
Also having a different subproject gives us the ability to choose the permissions again for that project. Joonas Kurtis Hanna: > Hello Replicants, > > I didn't get any responses to this thread. If you have any thoughts on > any of these items, even if it is only one or two comments, please feel > free to share them. Also, no pressure to respond if you are busy or > don't have anything worth sharing. > > In Solidarity, > Kurtis > > Kurtis Hanna: >> Hello Replicants, >> >> OSUOSL recently finished updating our Redmine to version 4.0.4. [0] >> >> Now that it is completed, it might be worth it to have a discussion >> about whether we want to make a few modification to our now up-to-date >> Redmine instance since it is used so much by the Replicant project. >> >> I should start by mentioning that I haven't interacted much with other >> project's Redmine instances and very well might not understand the >> benefits of doing things differently than Replicant has already done >> with our instance, so please accept my opinions below as humble >> suggestions only. >> >> Here's a few topics that we should perhaps explore: >> >> 1) Projects and Subprojects >> >> In Redmine we can create Projects and Subprojects. Up until now we have >> only used a single Project which has the following modules enabled: >> Wiki, Calendar, Time tracking, Gantt, Issue tracking, and Forums. I also >> just enabled the News module on the Project, but feel free to disable it >> seems unneeded. >> >> Denis made a subproject of our main Replicant project called 'Replicant >> infrastructure' in order for us all to see what a subproject in Redmine >> looks like. We can use it as a temporary sandbox to test it out. Do you >> guys think that having subprojects would help us organize ourselves >> better on Redmine? >> >> One concern I have about it is that, especially with the wiki module >> enabled on subprojects, it would lead to data fragmentation. >> >> For instance, I'm not sure if any problems are solved by having this wiki: >> >> https://redmine.replicant.us/projects/replicant/wiki/ReplicantInfrastructure >> >> >> duplicated, linked to, or moved to a Replicant Infrastructure Subproject >> wiki here: >> >> https://redmine.replicant.us/projects/replicant-infrastructure/wiki >> >> I feel like our wiki guidelines regarding the naming of pages[1] >> accomplishes the problem that a subproject wiki tries to solve, but >> perhaps someone else can think of good reasons for us to have two wikis. >> >> I could perhaps see a benefit of having a subproject with only the >> issues and news enabled, but I haven't thought through the potential >> data fragmentation issues that might arise by doing this as much. >> >> Are any problems solved by having infrastructure issues listed in a >> subproject instead of separated into its own Category on a unified >> Redmine project? If filtering is the perceived benefit, it seems to me >> that the filtering options for issues in our main Project are already as >> granular as they can get. It even includes the ability to exclude any >> Categories, including Infrastructure, that you don't want to see. >> >> I seem to agree with this commenter's post on the subject, "[Redmine >> subprojects] are generally used for large projects when there are clear >> distinctions between both the groups of people working on different >> areas [and clear distinctions] between those areas". >> https://www.redmine.org/boards/1/topics/23075?r=23089#message-23089 >> >> Perhaps there will come a time to use subprojects, but it doesn't seem >> like we have the need for them currently. >> >> It is worth noting that the Redmine project themselves don't use >> Subprojects: [2] https://www.redmine.org/projects >> >> I should point out here that there is a redmine plugin[3] that adds the >> ability to make multi-project issues. >> >> 2) Should we make it easier to find our web facing git repo? >> >> The Redmine project seems to keep their projects's code in their redmine >> instance via the repository module: >> https://www.redmine.org/projects/redmine/repository >> >> We have the Repository module turned off in our Redmine instance and >> instead use the FSF's infrastructure to host our web viewable git repo >> at git.replicant.us. >> >> I'm in favor of continuing to use FSF's infrastructure to host our code, >> but it does make it more difficult to find our code in our Redmine >> instance than it is in Redmine instances that have a "Repository" tab >> that links to their git repo. >> >> We also don't seem to have any direct links to git.replicant.us on our >> main wordpress site. I guess we sort of used to have these links before >> our git atom feed broke (which we still need to remove). >> >> Would it be good to add a direct link to git.replicant.us on the top >> black banner of our main page where it says "Blog Wiki Tracker Forums" >> and also, if OSUOSL can do it easily, in between "Projects" and "Help" >> in the top left corner of all of the pages on our Redmine instance where >> it says: "Home My page Projects Help" >> >> The easiest way for new visitors to our main page to get to >> git.replicant.us currently seem to require them to navigate to >> ReplicantSourceCode [4] which take more clicks than it really ought to. >> >> 3) Plugins >> >> There are a number of Redmine plugins that we should at least consider >> adding. Here's a few of them: >> >> Agile - https://www.redmine.org/plugins/redmine_agile >> >> a) Displays Redmine Issues as task cards on an Agile board >> >> Checklists: https://www.redmine.org/plugins/redmine_checklists >> >> a) adds checklists >> >> Emojis - https://www.redmine.org/plugins/redmine_emojibutton >> >> a) Enables the use of emoji codes >> >> b) Insert emojis with new button in issue/wiki editor >> >> Lightbox - https://www.redmine.org/plugins/redmine_lightbox2 >> >> a) Lets users preview image, pdf and swf attachments in a lightbox >> instead of requiring them to download images that aren't properly embedded. >> >> People - https://www.redmine.org/plugins/redmine_people >> >> a) Enables users avatars >> >> b) Enables more granulated elastic permission rules, >> >> c) Enables popup notification, reminders or warnings to a particular >> page, group of users or all users, including recurring notifications, or >> reminders >> >> 4) I've closed all the 4.2 related tickets since we are no longer >> supporting that version. Is there a benefit to also closing Replicant >> 4.2 here [5] as was done with Replicant 1.5, 2.2, 2.3, and 4.0? >> >> 5) Should we remove PDF files of issues? Here's an example: >> https://redmine.replicant.us/issues/1946.pdf I've noticed in the past >> that these .pdf files end up getting found by search engines and makes >> for an odd experience when one clicks on the link. >> >> In Solidarity, >> kurtis >> >> [0] https://www.redmine.org/versions/151 >> [1] >> https://redmine.replicant.us/projects/replicant/wiki/DeveloperGuide#Wiki-guidelines >> [2] https://www.redmine.org/projects >> [3] https://www.redmine.org/plugins/redmine_multiprojects_issue >> [4] https://redmine.replicant.us/projects/replicant/wiki/ReplicantSourceCode >> [5] https://redmine.replicant.us/versions/39/edit >> > > > _______________________________________________ > Replicant mailing list > [email protected] > https://lists.osuosl.org/mailman/listinfo/replicant >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Replicant mailing list [email protected] https://lists.osuosl.org/mailman/listinfo/replicant
